


\section{Discussion}

SALADS has a number of limitations. In this section, we examine
each of them and discuss the possible solutions.


The first limitation is our current design does not support the
protection of the meta data of our randomization record.
The problem is suppose an
attacker can read arbitrary memory location, and thus he can read
the randomization record and extract the seed. With the seed, the
attacker can predict the memory layout of the data structure
instance. This is a common problem to compiler-based techniques,
such as Stackguard~\cite{Stackguard}, and G-Free\cite{G-Free}. One
possible solution is we can adopt the encryption data protection
method proposed by Harrison~\cite{Harrison07}. His method suggests
that we can introduce an encrypted data access control mechanism to
prevent the external code to access the randomization record. This
method has to be implemented in a lower layer with the higher
privilege.
%For example, for user-level application, we could implement this
%mechanism into the kernel using system call; while for kernel, we
%could implement it into the VMM layer if there it does have one
%through hypercall. Though such design will suffer the context switch
%and introduce more performance overhead.


The second limitation is an attacker may resort to the code-reuse
techniques to predict the memory layout of the data structure, for
example, he could reuse the routine (e.g., \texttt{Update\_Record})
to get the memory layout of the data structure. Though currently we
do not have a solution to prevent it yet, we have increased the difficulty to
launch such attack. For example, most code reuse techniques such as
ROP~\cite{ROP} and Return-into-libc~\cite{RIL} require the memory
exploits. However, as demonstrated in Section 5, SALADS can be used
for defeating some of the memory exploits by randomizing the data
structure layout in library code (e.g., \texttt{malloc\_chunk}) or in the
programs (e.g., \texttt{ssl\_session\_st}). With our data structure
randomization and existing address space
randomization~\cite{ASLR1,ASLR2,ASLR3}, we believe it makes the
code-reuse attack more difficult though it is still possible.


%Thirdly, an attacker may use a brute force guessing technique (e.g.,
%\cite{deASLR3}) to get our randomization seed and reuse it to
%construct an attack. However, even though the attack succeeds in
%guessing the right seed, SALADS can dynamically change the seed of
%the data structure instance. Thus, the attacker may fail to reuse
%his seed to predict the memory layout of the same data structure
%instance after our seed has been changed.

%
%The dynamic randomization
%feature of SALADS is especially beneficial to the multi-threaded web
%applications (e.g., httpd). For example, two threads may reuse the
%same data structure instance, once the attacker exploits one thread
%and get the key, he may not reuse the key for exploiting the other
%thread after the key is changed.

%\subsection {Re-randomization of the Data Structure}

%Finally, SALADS does not provide the re-randomization after
%de-randomizing a data structure. This is because in our current
%design, when SALADS encounters pointer operations (e.g.,
%\texttt{void * p=\&q;} and \texttt{q} is a data structure instance),
%it will never re-randomize the layout of the instance (e.g.,
%\texttt{q} in this case) again. This may create the possibility for
%the attacker to attack a de-randomized instance. Thus,
%re-randomizing a de-randomized instance is one of our future
%efforts.


% Although pointers-to analysis may
%provide the set of pointers that reference the instance, SALAD still
%suffers the challenge that how to select the re-randomization point
%after which no pointers with different type will access the instance
%in different execution context.
